1. Field of the Invention
The present invention relates generally to techniques for maintaining programming systems, and more particularly, to methods for selecting which sets of program corrections or “patches” are identified for installation in a reactive manner.
2. Description of the Related Art
When an operating system, such as Hewlett-Packard's version of UNIX “HP-UX,” receives new program files that are to be added to a given system, the files are delivered gathered into filesets having names, such as FS1, FS2, and so on. These filesets are installed on a given system by a process that unpacks and, possibly, uncompresses the files and places them onto the hard disk drive of that system. As in shown in FIG. 1, each fileset can contain a small or large number of files. The FILESET FS1 is shown containing the files FILE A, FILE B, . . . and FILE F. Likewise, the FILESET FS2 is shown containing the files FILE J, FILE K, . . . and FILE P. Of course, a fileset typically contains many more files than this. Some of these files would be program files, some would be data files, some would be graphic image and multimedia files, depending upon the particular nature of the system and the particular nature of the programming system being installed.
Patches, or corrected/updated sets of files, are also delivered to a system as collections of filesets. In the HP-UX system, it is customary that the filesets in a patch have the same names as the installed filesets. A patch fileset contains updated versions of some (possibly all) of the files in the system fileset having the same name. A given patch PATCH_5 contains new features and fixes or repairs for specific defects. Descriptions of the new features and of the repaired defects are contained in a text file that is maintained in a central database for each patch and that is searchable for words and phrases. FIG. 2 illustrates an example patches database. Accordingly, a systems administrator may search through the patch text file database and locate patches that repair particular defects or add particular features.
Over time, a first patch may be replaced by a second patch which contains all the fixes and new features of the first patch plus additional changes. These additional changes are called incremental fixes. The new patch then SUPERSEDES the previous patch. With reference to FIG. 4, the PATCH_4 at the root of the patch tree 40 supersedes all of the three patches to the left in this simple linear search tree. Historically, the first patch created was patch_1. It was superseded by PATCH_2, which was later superseded by PATCH_3, and that patch was later superseded by PATCH_4 which now resides at the root of the patch tree 40. Typically, large systems will contain large numbers of filesets, and these will be updated by the patches in multiple disjoint patch trees (i.e. a patch will appear in at most one tree). Accordingly, FIG. 6 illustrates a possible set of four patch trees 62, 64, 66, and 68 all comprising a set of patches 60 that are used to update a given system. The set of patch trees shown in FIG. 6 is selected by first determining what filesets a given system contains and by then, with reference to a patch tree database such as that shown at 30 in FIG. 3, selecting the root patches for all the patch trees that contain filesets having the same names as the system filesets. (See also FIGS. 4 and 12 and the accompanying text in U.S. Pat. No. 7,020,875.)
In some situations, as illustrated in FIG. 3 at 30 and also in FIG. 5 at 50, two or more patches will be replaced by a single patch. Thus, PATCH_6 SUPERSEDES both the patches PATCH_5 and PATCH_8. This is represented in the search tree by PATCH_6 forming the root of a sub-tree having the two branches PATCH_5 and PATCH_8. Referring now to FIG. 5, the same patch tree shown in FIG. 3 is shown at a later point in time. At some point in time, a new patch PATCH_9 was added which was not part of the original patch search tree but which initially formed a single isolated patch search tree having only one patch element. Then a new patch PATCH_7 was created which combined all of the updates and changes contained in the patches 5, 6, 8, and 9. Even later on, PATCH_7 was superceded by a new patch PATCH_10, thus forming the patch tree 50 shown in FIG. 5. The root patch in the patch tree 50 is the PATCH_10. That patch and PATCH_7 form the trunk of this searchable patch tree, which then branches into two branches, one containing PATCH_9 and another containing PATCH_6; and the PATCH_6 branch of the tree then branches again into the two patches PATCH_5 and PATCH_8. As can be seen, a patch tree can become quite elaborate over time as many patches are combined into a smaller number of newer patches. When placed into a patch tree database, as shown in FIG. 2, a patch tree can be searched in an automated manner.
Patch applications are designed to identify, analyze, and deliver patches to customers. A patch is applicable to a system if at least one of the filesets contained in the patch has already been installed on the system and no successor to the patch is already installed on the system. During the identification phase, algorithms identify starting locations on patch chains and traverse the chains, analyzing the attributes of the patches attempting to identify the most appropriate patch for the customer.
Known reactive patch applications have utilized knowledge about given computer systems. In patch terminology, reactive refers to searching for a patch to fix a particular problem. However, such applications have only used information regarding the hardware (HW) version and the operation system (OS) version of the computer system. As such, the patch application is forced to assume all patches for the specified hardware version and operating system version are applicable. The patch application is unable to eliminate many non-applicable patches from the search space. Indeed, when searching for patches using the patch application and specifying only the HW and OS, the resulting list of patches may be very large and may contain many patches which are not applicable. Moreover, when performing dependency analysis for patches given only the HW and OS, the patch application must assume that none of the dependents are installed on the computer system. The term “dependent” patches refers to a patch that requires the additional installation of a different patch found on a separate patch tree. A later patch includes a dependent patch within it. As a result, some dependent patches included are unnecessary because they (or one of their successors) are already installed on the customer's system